In a virtual machine (“VM”) environment or cloud virtualized environment, such as in a telecommunications service provider system, congestion issues might arise where one or more applications might request more and more hardware resources, without end and without any means for monitoring the actual hardware (or hardware resource) constraints on the host system. Without any checks on the resource allocation associated with the host system, the one or more applications might request more and more hardware resources until the host system finally and catastrophically crashes.
Currently, existing application level congestion control state machines and push back interrupts are hardware specific to vendor platforms. In other words, even though existing application congestion controllers and congestion control state machines might utilize the orchestrator and/or hypervisors to add resources, such elements do not have the functionality for receiving limitations from the cloud to perform push backs to bound and/or reduce the use of hardware resources, and thus cannot ensure that if the application is attacked or running over capacity the application will not crash the system.
In addition, even though different hardware from a single vendor might provide for load push back mechanisms and/or dedicated scan rates at the north, south, east, and west bound interfaces of an application congestion controller, by using a protocol with an intelligent device for “buffer monitoring,” such congestion control systems are vendor-specific and do not allow for cross-application congestion control that is required in a global VM environment. Moreover, interfaces in existing VMs are not designed to provide congestion control state inputs. Further, existing congestion control systems are typically one-way controls, without sufficient feedback.
As a result, the system can be vulnerable to system hacks, mass call events, or both, where the applications exhaust and consume resources without any limitation or any push back or throttle down application message especially in a mixed application environment from the orchestrator that manages the overall resources of the VM environment. Without such throttling, and load shedding mechanisms the overall inability can render the system too busy to process normal traffic, and can result in the crushing of services and may cause the entire system network to crash.
Further, given that applications are mostly stateless and VM sessions can tolerate some small delay, congestion is only monitored at the CPU, memory, and storage levels (not interface), and additional resources are added when an application nears exhausting its allocated resources. The problem with this approach is that turning all communications into the same area with millions of users creates a “mass call event” (e.g., a “September 11” scenario) where use demand can exceed the resources across a cloud environment and exhaust all resources to the level of unacceptable non-performance. Normally, the physical limitations of dedicated hardware act as the threshold for the system triggering a load shedding survival mode. Once utilization approaches the limits of the equipment, non-critical processes are shed via the application congestion engines. Once an application is placed inside of a VM environment those limits are unknown, and can actually be dynamic available or unavailable. Therefore, to retain the application survivability, those utilization limits need to be communicated from the VM orchestrator to the application when congestion and resource limits have been reached.
Hence, there is a need for more robust and scalable virtualization congestion solutions.